Computer users are more and more frequently using mobile devices to perform tasks once thought to require the power of desktop computers. Mobile devices today, such as smartphones, are more powerful than desktop computers of just 10 years ago, and are advancing at a pace faster than their desktop counterparts did. Current smartphones allow running applications, browsing the web, and editing documents in addition to the more traditional smartphone function of making calls. Many mobile devices include a graphics-processing unit (GPU) for offloading graphics intensive processes from the central processing unit (CPU) to more specialized hardware. Mobile devices have ever-increasing display resolutions that involve pushing more and more pixels to the screen to display content.
With the rise in computing power of mobile devices, an important consideration is battery life. Although mobile devices are powerful, leveraging the full computational power of the device all the time would lead to a battery that did not last very long. Most mobile device users expect their devices to last at least a day on a standard charge, so that the user can use the device as needed throughout the day and charge the device at night. One factor that influences mobile battery life is the execution of underlying subsystems provided by the mobile device for applications to leverage. Subsystems can include application platforms, such as a Java Virtual Machine (JVM), MICROSOFT™ SILVERLIGHT™ Mobile, the MICROSOFT™ .NET™ Compact Runtime, and so forth.
Prior runtimes have attempted to automate the task of tuning the runtime to allow the runtime to shut itself down or turn off parts of the runtime to conserve power and extend battery life. Unfortunately, the runtime often has very little knowledge of how it will be used by an application that invokes it. If the runtime chooses to shut down a component or service that the application will soon attempt to use, then the runtime may introduce undesirable application delays and cause the mobile device to feel sluggish to the user as the runtime “wakes up” to handle the user's requests.